1. Field of the Invention
The present invention relates generally to a mobile broadcasting system, and more particularly to a traffic encryption key distribution method for a mobile broadcast service, which is applied to an OMA BCAST Service Protection and Content Protection architecture in Digital Rights Management (hereinafter “DRM profile”), in an Open Mobile Alliance Broadcast (OMA BCAST) service system, and a system for the same.
2. Description of the Related Art
In the mobile communication market there is constant demand for producing a new service through the re-combination or integration of existing technology. Today developing communication and broadcast technology in conventional broadcasting systems or mobile communication systems is at the stage of providing a broadcast service through a mobile terminal (hereinafter “terminal”), such as a mobile phone, a Personal Digital Assistant (PDA), and the like. The merger of mobile communication services and Internet Protocol (IP) is at the forefront of development of next generation mobile communication technology, combined potential and actual market demand as described above, rapidly increasing user requirements for a multimedia service, service provider strategy intending to provide a new service, such as a broadcast service, in addition to an existing voice service, and interests of Information Technology (IT) companies that can meet the market demand and strengthen their mobile communication businesses.
Meanwhile, the Open Mobile Alliance (OMA), a standardization group for applications of terminals, has been conducting research on standards for interlocking between individual mobile solutions. The main role of OMA is determining various application standards for games for mobile communication, Internet services, and the like. Particularly, an OMA Browser and Content Mobile Broadcast Sub Working Group (OMA BCAST), one of the working groups of OMA, is conducting research on technology for providing a broadcast service by using a terminal. Hereinafter, a broadcasting system (hereinafter “mobile broadcasting system”) discussed by the OMA BCAST working group will be briefly described.
FIG. 1 is a block diagram illustrating the network architecture of a general mobile broadcasting system.
In FIG. 1, a Content Creator (CC) 10 is a BCAST service content provider, wherein the BCAST service may include the conventional audio/video broadcast service, file download service (e.g. music file or data file download service), and the like. A BCAST Service Application unit (BSA) 20 has a function of receiving data from the Content Creator 10, handling the received data in the form appropriate for a BCAST network shown in FIG. 1, and generating BCAST service data. In addition, the BCAST Service Application unit 20 has a function of generating standardized metadata necessary for a portable broadcast guide. BCAST-1 to BCAST-8 are interfaces among entities.
In FIG. 1, a BCAST Service Distribution/Adaptation unit (BSD/A) 30 has a function of setting up a bearer to be used for transmitting the BCAST service data provided from the BSA 20, a function of determining a transmission schedule for the BCAST service, and a function of generating a portable broadcast guide. A BCAST Subscription Management unit (BSM) 40 manages subscriber subscription information for reception of BCAST service, information on provision of the BCAST service, and device information on a terminal for receiving the BCAST service.
A terminal 50, which is capable of receiving BCAST service, has a function of being able to access a cellular network according to the capability thereof. A Broadcast network 60 is a network for transmitting BCAST service, such as a Digital Video Broadcasting—Handheld (DVB-H), a Third Generation Partnership Project Multimedia Broadcast and Multicast Service (3GPP MBMS), Third Generation Partnership Project 2 Broadcast and Multicast Service (3GPP2 BCMCS), and the like. An Interaction Network 70 transmits BCAST service on a one-to-one basis, or interactively exchanges control information and additional information related to the reception of the BCAST service, and may be, for example, an existing cellular network.
Generally, in BCAST service, when a broadcast service managing server transmits encrypted service data, a plurality of terminals receive the encrypted service data. In this case, each of the plurality of terminals decrypts (i.e. deciphers) the encrypted service data, which has been provided from the server, through use of a pre-acquired encryption key (e.g. cryptographic key), thereby being able to use a corresponding service.
In connection with this, methods for encrypting broadcast content and service are roughly classified into two categories, i.e. service protection and content protection. Service protection relates to protection of a transmission channel between the BSD/A 30 and the terminal 50, and content protection relates to end-to-end protection between the BSA 20 and terminal 50.
Meanwhile, an OMA BCAST SPCP DRM profile implements a key management scheme for mobile broadcast services. Two types of keys, i.e. Long-Term Keys (LTKs) and Short-Term Keys (STKs), are defined for access and provisioning of service and content. The LTKs are used for setting up (i.e. conditioning) access criteria for STKs according to a service subscription policy for users, by encrypting the STKs through use of the LTKs. The STKs are used to actually encrypt traffic. The LTKs and STKs must be periodically updated, wherein the lifetime of the LTKs are much longer than that of the STKs. The LTKs and STKs are provided to the user by a Rights Issuer (RI).
Hereinafter, description on key management in a DRM profile will be given in detail.
FIG. 2 is a diagram illustrating a key hierarchy defined in a general DRM profile.
Referring to FIG. 2, an Inferred Encryption Key (IEK) 120 related to Registration Keys 100 and a Public/private key pair 110 are used to encrypt long-term keys which are called a Service Encryption Key (SEK) 130 and a Program Encryption Key (PEK) 140. SEKs and PEKs are transmitted to each terminal through Generalized Rights Objects (GROs). Also, the Generalized Rights Objects include permissions linked to content and other attributes. The SEKs and PEKs function to protect each subscription and program, which can be purchased in one unit. The service corresponds to one program channel, a part of a channel, or a group of program channels.
The SEK 130 is provided to a subscribed user having subscribed for the whole service, that is, a user who continuously receives content and regularly updated SEKs even without a separate request as authentication is successfully achieved. Such a scenario is called “subscription-based access.”
The PEK 140 is provided to a user who is restricted to accessing a service only within a predetermined time interval, or a user who is restricted to using a program by the unit service. In order to obtain access to the next program or a consequent time interval, a corresponding user must make an additional purchase request. That is, one program and a certain time interval may be associated with one or more PEKs. Such a scenario may be called “Pay-Per-View (PPV)-based access.”
The SEK is an intermediate key, and does not directly encrypt content, but encrypts a Traffic Encryption Key (TEK) 150 or PEK when necessary. The PEK is used to encrypt TEKs.
A terminal may receive a Service Authentication Seed (SAS) and a Program Authentication Seed (PAS), respectively, which are used to authenticate messages delivering TEKs, together with an SEK and a PEK. The SEK and the SAS are inclusively designated as a “Service Encryption and Authentication Key material (SEAK).” The PEK and the PAS are inclusively designated as a “Program Encryption and Authentication Key material (PEAK).”
The TEK 150 is an STK. The TEK 150 is included in a Short Term Key Message (STKM) and is then transferred, and is encrypted by an SEK or PEK when necessary. The TEK must be frequently updated for security. Such a frequent update requires the consumption of a large amount of bandwidth, which is a serious disadvantage of the key management system. That is, in order to ensure successful delivery of a TEK and simultaneously, to avoid interruption of service, STKM messages must be more frequently transmitted.
FIGS. 3 and 4 are diagrams showing examples of the aforementioned key distribution. First, FIG. 3 is a diagram illustrating a key distribution flow of an SEK and a TEK, which are provided in a general subscription-based access environment.
Referring to FIG. 3, in the subscription-based access environment, an SEK lifetime (SEK LT) is calculated to be “n” multiplied by a TEK lifetime (TEK LT). Before the current service encryption key “SEKy−1” expires, an RI has to generate and transmit a new service encryption key “SEKy” to a service subscriber in a GRO in step 210. The SEKy is encrypted by one of registration keys. Then, after the current service encryption key “SEKy−1” has expired, PEKs delivered together with TEKx+1, TEKx+2 . . . , TEKx+n through an STKM are encrypted by the SEKy. Also, before the SEKy expires, the RI generates and transmits a new service encryption key “SEKy+1” to the service subscriber in step 220.
FIG. 4 is a diagram illustrating a supply flow of an SEK and a TEK in a general PPV-based access environment.
Referring to FIG. 4, in the PPV-based access environment, a PEK lifetime (PEK LT) is calculated to be “m” multiplied by a TEK lifetime (TEK LT). Here, m≦n.
For example, when it is assumed that PEK LT=0.5*SEK LT, the PEK must be updated two times more frequently than the SEK. For example, it is assumed that the user makes two purchase requests for two consequent time intervals associated with PEKz and PEKz+1. In this case, before a TEKx+1 (which is a first TEK related to the PEKz) is used, an RI transmits a new GRO including the PEKz to the user in step 310. The PEKz is encrypted by an SMK1 shared only between the corresponding user and the RI. Before a TEKx+m+1 (which is a first TEK related to the PEKz+1) is used, the RI transmits a new GRO including the PEKz+1 to the user in step 320.
However, when the user does not issue a further purchase request until a TEKx+n+1 has been used, the RI does not transmit a PEK for the TEKx+n+1 to the user, so that the user cannot decrypt TEKs beginning from the TEKx+n+1. Accordingly, there is a problem in that the user cannot use a service or service content requested by the user.